Many software applications (e.g., e-mail) are designed to operate on both a client device and a server system, or on a client device with support from a server system. These applications enable a user to freely create, receive, transmit, and modify data regardless of whether the user is operating on the client device or on the server. Synchronization of data between the client and the server allows consistency to be maintained between the application data residing on the client and the server. Synchronization is important as, for reasons of efficiency, a client device generally operates mainly with locally-stored data. For example, in the case of a client-server email application where an e-mail client executes on a portable device (such as a laptop or a mobile telephone) in communication with a separate email server, synchronization of email application data requires that email messages received at the email server are downloaded to the email client (this is called downhill synchronization) and operations performed on the locally-stored email data by the client are subsequently uploaded to the email server (this is called uphill synchronization).
Data synchronization can operate between a client and server more or less continuously as long as the server and the client remain in communication. However, synchronization becomes more challenging when the server and client have been out of communication for while, either due to a communications outage or the need for the client to operate in an offline or “airplane” mode, or when the client device is being newly configured to connect to the server, in which case the client device has little or no local application data stored in its memory. In such a situation, a large amount of data received at the server during a communication outage will not have been synchronized to the client when the client reconnects to the server, nor will offline client operations have been synchronized to the server. The subsequent synchronization step, where a large amount of application data needs to be downloaded to the client, is sometimes referred to as “priming the cache” of the client device.
Prior approaches to priming the cache of a client device are inconvenient and/or slow. This is especially the case in those prior implementations that require priming to be completed before the client is able to start operating with the downloaded application data. Priming the cache in this way can be a long process that requires a user to wait for a substantial time prior to being able to use the locally-stored data.
For example, in one prior implementation for priming the cache of a client device with email application data, a substantial portion of the email data stored at the server is first written onto one or more CDs, then a user physically copies the data from the CDs onto a client device (such as a laptop). In other implementations, the set of data to be synchronized to a client is downloaded via a network connection, which means that a communication outage could interrupt a lengthy downhill synchronization operation, rendering the client device unable to use any of the downloaded data.
In other implementations of downhill synchronization, the data to be synchronized to a client is downloaded from the server chronologically, from oldest to newest data, which means that, should the client go offline prior to completion of synchronization (and was able to use the incomplete data), only the oldest data would be available on the client device, which would be frustrating to the user—especially in the case where the user no longer is able to connect to the server.
Since client devices generally have less memory available to store application data than servers, a more desirable method of synchronization of data from the server (which is often a subset of all data stored on the server) to the client is preferred so that a user of the client can have immediate access to the most relevant data after each synchronization.